QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930046.txt

Internet Message Format | 1994-06-04 | 25KB

Date: Thu, 18 Feb 93 04:30:13 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #46
To: tcp-group-digest


TCP-Group Digest            Thu, 18 Feb 93       Volume 93 : Issue   46

Today's Topics:
                    16550 uart chip source in BC.
            ARRL Petition to "kill" AX.25 -- some factoids
                             Book on NOS!
                            Death of AX.25
          looooooooooooooooooooooooooooooooooooong messages
                          New ax25? (7 msgs)
               New files at UCSD.EDU PNEWS & BM 3.3.2b
                        new firmware? (2 msgs)
                            nos bug query
                 NOSintro - TCP/IP over Packet Radio
                              subscribe

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 17 Feb 93 11:17:21 pst
From: JAMES_DEAN <[e-mail]>
Subject: 16550 uart chip source in BC.
To: [e-mail], [e-mail]

The SysAdmin at the QUESTOR Project, Steve Pershing <[e-mail]> in
Vancouver is offering the National CP16550AFN chip for $16 CDN, each.

Send him an e-mail to order. I saw his offer posted in the 'comp.dcom.modems'
news list dated 13 Feb 1993, and have ordered two for myself. [His offer
there was for $12 US/plus shipping]. Phone numbers given in his message
are: (+ 604) Voice: 682-6659, Data: 681-0670 and Fax: [phone]

As a side note, are there any complications in simply replacing the
16450 with a 16550? The manual I have says they are pin-for-pin except for
two pins, one of them NC on the 16450. Does a standard PC application of
the chip care about that difference?

Cheers,
James.
--
James Dean
National Research Council Canada
Dominion Radio Astrophysical Observatory
Penticton, BC
[604]493-2277
<[e-mail]>
<ve7jwd@ve7ehs>

------------------------------

Date: Thu, 18 Feb 93 05:56:23 UTC
From: [e-mail] (Tom Clark -- W3IWI)
Subject: ARRL Petition to "kill" AX.25 -- some factoids
To: [e-mail]

There have been some tcp-group comments that I interpret as flamage and/or
misinformation concerning the ARRL petition to the FCC that drops the AX.25
requirement. Let me try to set the record straight by giving a brief review
(seen with my personal myopic biases) of the background. For those of you
who want to read the complete text of the ARRL's proposal, it is available
by anonymous ftp from   tomcat.gsfc.nasa.gov  in   ~/public/fcc/arrl_hf.txt
(42706 bytes long). Thanks to Dave Speltz, KB1BD for making the material
available.

Note that this proposal only discusses the HF bands, 30 MHz and down. As the
"new boy on the block" packet has had a hard time shoe-horning itself into
a very congested spectrum with a new technique. The present automatic HF
packet activity using AX.25 is carried out under the aegis of an FCC Special
Temporary Authorization (STA) that dates back far too many years. The bulk of
the existing rules date back to 1934 and clearly new techniques needed to
be accommodated. The ARRL had made two previous abortive attempts to replace
the STA with some suitable new rules that would allow for automatic digital
operation on HF.

The first attempt to write some rules that would permit automatic operation
ran afoul of the RTTY/AMTOR folks and the International powers that be
(specifically IARU, more specifically Region 2, and even more specifically
from Central and South American countries). That proposal was withdrawn
"without prejudice". Those who worked hard on that proposal (W4RI, AD7I,
WA7GXD and others) felt pretty bloodied by the experience.

In late 1991 & early 1992, the ARRL appointed a new Digital Committee (DC),
charged them with solving the problem and published a questionnaire in QST
and RTTY Journal. The Packeteers didn't get the word and were not very
responsive. The DC took what responses it got (mostly from the RTTY and AMTOR
users) and wrote a proposal which was published early last summer. The Packet
community rose up in arms, said this isn't going to work, and made life
generally unpleasant for both the DC and the ARRL BoD. The ARRL BoD in August
decided that some of those active in the current packet STA needed to meet
with the DC to try to find a compromise. The STA community elected the "Gang
of Five" (GOF) consisting of W0RLI, KD7XG, WA0CQG, AD8I and W3IWI to met with
the DC in late September to solve the problem. Through August and September
the Packet community formed and active working group  ([e-mail]) which
tried to sort out the our view of the alternative universe.

Then, Lo and behold at the IARU Region 2 meeting in Curacao in early September,
the politicos decided that Packet did have a place on HF and the managed
to develop a workable band plan. One thing that had changed was that the
Latinos now realized how useful HF packet networks were in developing
countries and they WANTED space for them.

Given the new IARU position, the DC and the GOF unanimously negotiated a
compromise that seemed acceptable to all factions and which adhered to the
IARU band plan, and recommended this as the position the ARRL should take
vis-a-vis digital communications on HF. It recognized that all the "modes"
were serving a useful purpose, and it said that they were all evolving.
Digital communications a few years hence probably would not look like
ANYTHING now on the air. We would see adaptive DSP modems, convolutional
encoding to improve error rates, block-oriented "hole-filling" protocols
(a la the PACSATs), etcetera etcetera. Nobody wanted to see us stuck with
obsolete protocols be they ordained by the CCITT (like TOR) or VHF packet
practice (like AX.25). I was the one who suggested that it should be adequate
to have the protocols in use be published (without saying where). My idea
was that we could essentially follow an RFC-like schema, with protocols
published for comment and available openly for anyone who really wanted
to figure out what the bits meant.

When the ARRL Board finally acted on the DC report, the fine-tuned the
frequency segments (mainly to avoid tromping on the 40 & 15M novices so much)
but I was VERY relieved to see that they let stand the "published protocol"
wording.

At the DC/GOF meeting, the main dissension concerned "semi-automatic" op-
eration (which is what the AMTOR and RTTY MSO people claim the have been
doing legally for many years), wherein at least one end of a path has a human
operator. The GOF felt that this was a subterfuge, operation is either
automatic or it ain't (you can't be semi-pregnant!). In the report we
agreed to disagree. The ARRL BoD dropped all references to "semi-automatic"
operation, and the proposal only uses the words automatic and unattended.

The petition has been filed with the FCC. To my knowledge it has not been
assigned an RM number and the comment period has not been opened. But when
it is opened, I urge that the advanced networking community (represented
by the people in this august group) should support it wholeheartedly. If
the FCC accepts the premise that amateurs can develop new, cost-effective,
efficient technologies on the HF bands where the "wire is incredibly poor",
then we have strong grounds to offer a similar solution to make a "better
AX.25" (or A-802.x or whatever). FYI, when the ARRL submitted the petition
to the FCC, they had the current HF STA extended until the RM procedure
ran its course.

------------------------------

Date: Wed, 17 Feb 93 06:31:38 MST
From: [e-mail] (Bob Nielsen)
Subject: Book on NOS!
To: [e-mail]

John Ackermann   AG9V <noao![e-mail]> writes:

> You (Russell Nelson) write:
> >
> > Yeah!  Finally!  Ian Wade, g3nrw, wrote a book on NOS.  I don't know
> > enough about amateur radio to say if it adequately describes the
> > AX.25, PBBS, and NET/ROM stuff.  I can say for sure that it explains
> > things I never understood before.
>
> I got a complimentary copy from Ian on Monday.  I haven't had a chance
> to do more than dip into it yet, but it appears to be <very> well
> done... a serious cut above the usual Tab Books crap that most ham books
> seem to be these days.
>
> I think I'll probably be recommending it to people who want something
> more substantial than the currently available docs (mine included...).
> Though he may not cover a lot of territory that the existing docs don't,
> with the luxury of 300 pages to work with he can do a lot better job of
> explaining things.
>
> John AG9V
>

I noticed a new version of Ian's nosview at ucsd.edu in the /incoming
directory (I forget the exact path).

Bob Nielsen W6SWE
ax.25: [e-mail]    Internet: [e-mail]
amateur IP: 44.124.12.16         CIS: 71540,2364

------------------------------

Date: Wed, 17 Feb 1993 10:50:36 -0500
From: [e-mail] (k1io, FN42jk)
Subject: Death of AX.25
To: [e-mail]

<set mode=ballistic>
IS THIS THE ARRL UP TO ITS TRICKS AGAIN?

Sheesh!  Requiring a Morris Code (that's the county; Vail invented the
code) test in order to route packet?  That's insane, but totally in
keeping with the ARRL traditions.

But that's not all.  What really gets me is the term "accepted
protocol".  No lawyer would ever let that get into the CFR unless they
were acheing for a battle.  Accepted by Wayne Green?  Accepted by Fred
Goldstein?  Accepted by the ghost of Harry "Morse Forever" Dannals?
Accepted by the FCC?  In the latter case, the acceptance would take the
form of an enumeration in the regs., which right now means "AX.25", the
ARRL abomination.

One of two rules should apply:

1)  Identify every 10 minutes while in operation, and use any mode.

2)  Identify the call sign in every packet.  This breaks down into two
obvious mechamisms.

   2a)  Include "plain ASCII" in the protocol header.  Easy enough iff
 you grow a protocol from scratch.

   2b)  Use the same mechanism of Ident as AX.25, which is left-shifted
 ASCII in the header.  Odd but all that we're now allowed.

I'd be happy enough with Rule 2; that would let us move beyond AX.25.
But I'd also like to allow rule 2c as an option:

    2c) If using forward-error correction, identify in FEC-encoded
 ASCII, using a published FEC algorithm identified in the
 station log, and, if necessary, per rule 1) above.

I don't t hink the FCC wants to be overly restrictive, but if the League
demands it, they tend to go along.
   fred k1io

------------------------------

Date: Thu, 18 Feb 93 12:54:43 PST
From: "Jerzy Tarasiuk" <[e-mail]>
Subject: looooooooooooooooooooooooooooooooooooong messages
To: [e-mail], [e-mail]

when you really need to send something long, *PLEASE* pkzip and
uuencode it. And put some text info what it is. Your msg exceeded
100kB and some mailers may have a little trouble handling it.
Pkzip+uuencode would produce file 2 times shorter (50kB only)!
73's, JT

------------------------------

Date: Wed, 17 Feb 93 14:18:56 GMT
From: Michael Chace <[e-mail]>
Subject: New ax25?
To: Phil Karn <[e-mail]> (Phil Karn)

>>>>> Regarding Re: New ax25?; Phil Karn <[e-mail]> (Phil Karn) adds:

>Ok, well start by replacing the CSMA Medium Access Control. How about some
>form of Token Ring?

 Phil> There are, in my opinion, much better access protocols for radio
 Phil> channels than token ring. Token ring is complex, introduce long
 Phil> delays when the channel is nearly idle, and don't work well when
 Phil> loss rates are high (token recovery is the most complex and time
 Phil> consuming part of these protocols.)

 Phil> There are many things you can do to CSMA to make it work much
 Phil> better, you don't have to throw it out entirely.

 Not only that, but there are other practical and *implemented*
 systems to improve things - the DAMA extensions to AX.25 spring
 to mind. As far as I can ascertain, DAMA is catching on in some
 parts and does seem to make a noticeable difference.

 Perhaps some of the German list readers can comment further ?

 Mike
 ****

------------------------------

Date: Wed, 10 Feb 93 21:11:33 -0800
From: Phil Karn <[e-mail]> (Phil Karn)
Subject: New ax25?
To: [e-mail]

|> Yes, I think most of us agree AX25 needs replacing, lets experiment! with
|> something new.
|> I guess we have to define our problem a bit more and then we can start
|>working
|> on it.

Well, I wasn't talking about replacing AX25, I was talking about creating
a new network layer to sit between it and IP. But since you bring it up,
yes, we could certainly use a new link layer protocol.

|Ok, well start by replacing the CSMA Medium Access Control. How about
|some form of Token Ring?

There are, in my opinion, much better access protocols for radio channels
than token ring. Token ring is complex, introduce long delays when the
channel is nearly idle, and don't work well when loss rates are high
(token recovery is the most complex and time consuming part of these
protocols.)

There are many things you can do to CSMA to make it work much better, you
don't have to throw it out entirely.

Phil

------------------------------

Date: Thu, 18 Feb 1993 09:52:05 +1000
From: [e-mail]
Subject: New ax25?
To: [e-mail]

Lyndon writes;
> by backwards regulations?) Actually the whole concept of the SSID
> should be scrapped - it doesn't belong this far down the stack.

We need some method to differentiate different stations operating under the
one callsign.  I have up to 5 going at once, some on the same channel.

Using the callsign is fine but we also need SOME way to distinguish further
stations under that callsign.

Carl.
--
Carl Makin   (VK1KCM)  Systems Programmer
Internet:    [e-mail]
Amprnet:     [e-mail]
Work Phone:  [phone]

------------------------------

Date: Thu, 18 Feb 93 09:55:01 EST
From: [e-mail] (Dave Horsfall)
Subject: New ax25?
To: [e-mail]

[ Warren VK1XWT ]
> I would like to see callsigns kept as unique identifiers a la Ethernet
> addresses at the data link layer. But I agree, routing via callsigns
> is an abomination.

But for heaven's sake, let's not restrict it to an arbitrary 6 bytes!
This is what kept special event callsigns VI88NSW, VI150SYD etc from
being used on packet radio...


-- Dave

------------------------------

Date: Wed, 17 Feb 1993 15:24:50 -0800
From: Lyndon Nerenberg <[e-mail]>
Subject: New ax25?
To: [e-mail], [e-mail]

Well, the callsign doesn't belong in every packet, either - it's extra
overhead that just isn't needed. If you need to identify your transmitter
to comply with regulations, send an ID packet whenever its require. This
business to tying the callsign to the MAC address was a mistake.

------------------------------

Date: Thu, 18 Feb 1993 13:22:49 +1000
From: [e-mail]
Subject: New ax25?
To: [e-mail]

Lyndon Nerenberg <[e-mail]> writes;

> Well, the callsign doesn't belong in every packet, either - it's extra
> overhead that just isn't needed. If you need to identify your transmitter
> to comply with regulations, send an ID packet whenever its require. This
> business to tying the callsign to the MAC address was a mistake.

So how else are you going to generate a unique and reproduceable address
for that layer?  Using the callsign of the station with some other
identifying information makes it reasonably easy to keep the identification
unique.

BTW I'm not in the US and, at the moment, simply ID'ing every 9 minutes
isn't enough to keep it legal here. :-(  (Changes should be here soon
though that will make that legal)



Digressing a fair bit, Phil mentions he would like to see some sort of
"LAN" routing scheme setup below IP to give IP the fully connected network
it wants.  This seems a "good" idea to me as it would allow *much* easier
inter-operability between established (and dominating) IP networks and the
Amateur Service.

Instead of trying to patch IP we give it the sort of connectivity it
assumes is present and design a protocol specifically to handle the
problems a Radio network (such as we have) presents.


I suppose it would look something like this;

..
..
+--------------
| IP
+--------------
| "LAN" connectivity protocol
+--------------
| Link protocol
+--------------

It would present to IP a model of the network pretty much as if was a
*very* slow ethernet.

It would need to support the following;

Broadcasts,
Multicasts,
Point to point unreliable, unconnected delivery.

Full and half duplex links,
One way and multiple paths,

Anything else?

Comments?

Carl.
vk1kcm.
--
Carl Makin   (VK1KCM)  Systems Programmer
Internet:    [e-mail]
Amprnet:     [e-mail]
Work Phone:  [phone]

------------------------------

Date: Wed, 17 Feb 1993 22:22:39 -0800
From: Lyndon Nerenberg <[e-mail]>
Subject: New ax25?
To: [e-mail], [e-mail]

> So how else are you going to generate a unique and reproduceable address
> for that layer?  Using the callsign of the station with some other
> identifying information makes it reasonably easy to keep the identification
> unique.

Well, the address only has to be unique within the subset of stations
that can hear each other. I would use a 16 bit station address. When
a station comes on the air it picks a random value and broadcasts it
out the appropriate port. If the address is already in use the existing
address holder sends out a "sorry, try another one" reply, and the
process repeats until a unique address is found. (Now where have I
seen *that* before :-)

--lyndon

------------------------------

Date: Wed, 17 Feb 1993 20:03:30 +0200
From: Costas Krallis SV1XV <[e-mail]>
Subject: New files at UCSD.EDU PNEWS & BM 3.3.2b
To: [e-mail]

The new release of PNEWS (Pnews 1.05 ) is to be uploaded to ucsd.edu
in the incoming directory tonight.

The new release of BM v. 3.3.2b is to be uploaded to ucsd.edu
in the incoming directory tonite.

73 Costas SV1XV

------------------------------------------------------------------
|   Dr. K. Krallis  SV1XV *   Epsilon Software S.A.
|  ------
|  Internet:  [e-mail]
|  Packet radio: SV1XV @ SV1IW.ATH.GRC.EU
|  AMPRnet:   [e-mail]         [44.154.1.11]
|  Snail Mail:  P.O.BOX 3066, GR-10210 Athens, GREECE
------------------------------------------------------------------

------------------------------

Date: Wed, 10 Feb 93 21:11:11 -0800
From: Phil Karn <[e-mail]> (Phil Karn)
Subject: new firmware?
To: [e-mail]

At 10:37 2/9/93 -0800, Jeffrey D. Angus wrote:

|KISS Mode? The only things that would have to stay constant while re-using
|existing TNCs are the BELL-202 modem and the 8530 HDLC.

Actually, if you really want to redo amateur packet radio right from
the ground up, even these have to go. I'm becoming convinced that some
form of forward error correction (FEC) is essential, at least as an
option when links get bad, and this pretty much precludes HDLC framing.
I've been working on a sequential (Fano) decoder to a convolutional code
that runs fast enough on a 486 to handle a 56kb/s modem without any
trouble given channel bit error rates as high as several percent. This
would deal nicely with the 70cm radar problem we have in southern
California, among other things.

The reason FEC precludes HDLC framing is because you need a much more
robust synchronizing sequence to start off each frame. An HDLC flag is
much too short. You need something more like 32 or 64 bits long that
can be recognized reliably by a correlator even when a substantial
fraction (say 10%) of the bits are in error.

The Bell-202 modem I won't even talk about.

Phil

------------------------------

Date: Wed, 17 Feb 93 11:38:41 CST
From: [e-mail] (Andy Warner)
Subject: new firmware?
To: [e-mail] (TCP Group)

Phil Karn wrote :-
> [...]
> The reason FEC precludes HDLC framing is because you need a much more
> robust synchronizing sequence to start off each frame. An HDLC flag is
> much too short. You need something more like 32 or 64 bits long that
> can be recognized reliably by a correlator even when a substantial
> fraction (say 10%) of the bits are in error.

Some folks up here in the tundra of MN have been looking at a
chip that does Reed/Solomon (probably passe technology by now)
and serialisation, and scrambling. It's a production chip, it's
just not built for radio links.

One lesson that it took me a while to learn was that the current
way we use radio means that we can ignore things like ensuring
1's density, and stability of the symbol rate, since there are no
long-term effects (ie, a 1% change in rate during a 2 second
transmission is OK, but if it were a full time link, that kind
of drift would be clearly unacceptable.) Exploiting this fact
might let us simplify the tx, and allow the RX to track. Of course,
who's to say that the rx then doesn't become overly complex....

--
andyw. N0REN/G1XRL

[e-mail] Andy Warner, Cray Research, Inc. [phone]

------------------------------

Date: Wed, 10 Feb 93 21:12:36 -0800
From: Phil Karn <[e-mail]> (Phil Karn)
Subject: nos bug query
To: [e-mail]

For those of you having problems with file opens, you may need to increase
the number of MS-DOS FILE handles you allocate in your config.sys file.
Recent versions of NOS use file handles prodigously, especially now that
each session has a scrollback buffer (which is kept in a temporary file).

One of my reasons for rewriting my own stdio was to get around the
limit of 20 open files that's hard-coded into the Borland library.
(Yes, you can modify their source and recompile, but I had other reasons
too.) But to take advantage of this, you also need to allocate enough
file slots in MS-DOS itself. And that's what the FILES= command in
config.sys does.

Phil

------------------------------

Date: Wed, 17 Feb 1993 13:00:37 -0500
From: [e-mail] (k1io, FN42jk)
Subject: NOSintro - TCP/IP over Packet Radio
To: [e-mail]

Sounds like a good book.  Question:  Is the book mainly written for
end  users, as in "here's how to use NOS", or does it provide a
technical discussion of the code itself, as in "these are the modules,
here's how it works, etc."?
    fred k1io

------------------------------

Date: Wed, 17 Feb 93 16:31:26 GMT
From: [e-mail] (Pasquale Pizzichetti)
Subject: subscribe
To: [e-mail]

subscribe
-----
Pasquale Pizzichetti (IK3NGU) 10

------------------------------

Date: (null)
From: (null)
In terms of making inputs to the ARRL, be advised that Ed Juge, W5TOO has
resigned from the DC because of business pressures. I'm not sure who the
members are today. I'd suggest contacting the ARRL BoD liaison (Tom Comstock,
N5TC) or the HQ liaison (Jon Bloom, KE3Z). None of the GOF that helped the
DC come up with this solution has any advisory role -- our duties ended when
we got back on the airplane that fateful Sunday in Dallas.  In addition to
the DC, the ARRL has a "distant vision" committee (I know KA9Q and WA7GXD
are on it, but I've never seen a full list of members). One or both of these
ARRL committees would seem to be the place to start planting the idea that
we need more flexibility in developing future communications protocols. And
FYI, the small working group that was formed a few months ago still "meets"
as  [e-mail]  for anyone who wants to participate.  Send a request
to [e-mail] if you feel a compelling desire to join.

73 de Tom, W3IWI
[e-mail]

------------------------------

End of TCP-Group Digest V93 #46
******************************
******************************